This section introduces the GPIF feature from a hardware standpoint and discusses how to design with GPIF from the ground up. As the name suggests, the physical connection or interface to the external peripheral is highly configurable. This allows FX2 to become the solution for 99.9 percent of the parallel interfaces that exist. With the ability to run the physical interface at a maximum rate of 48MHz in 16-bit mode, the bottleneck in a USB 2.0 system should never be the actual GPIF interconnect itself. One of the objectives of this primer is to guide users down a path to get the most out of their GPIF designs in terms of performance over the physical interface. Thus, the general thought process for implementing successful GPIF designs is also discussed, allowing the user to understand and use a design flow methodology for current and future GPIF implementations. Debugging strategies are provided in Appendix A to guide the user on what the best approaches are for tackling GPIF design problems.

The GPIF (General Programmable InterFace) is a key feature of FX2 used to master an external peripheral without any external glue logic. The GPIF is basically a controllable state machine that allows the user to generate waveforms required by external peripheral read/write cycle timing. The CPU's role is minimal; as it basically only has to load the micro code that defines the waveform behaviors into designated FX2 on-chip RAM space, and manages how they are executed in the application firmware.
 

Figure 5. GPIF Interconnect Diagram

IFCLK (bi-directional)
IFCLK can be either an input or output signal and is determined by what the system requirements are. As an output signal, IFCLK can be driven by the FX2 at either 30 MHz or 48 MHz. As an input signal, its range is from 5-48MHz. If an external IFCLK is used in the design, it becomes the reference clock for all GPIF operations. Note that the GPIF can also run on an internal 30 or 48 MHz clock.
 

GPIFADR[8:0] (output only)
GPIF can use GPIFADR[8:0] to provide address lines for peripherals that need them. These are output only signals and the value presented on this bus can be auto-incremented.
 

FD[15:0] (bi-directional)
This is the data bus used by GPIF operations and is the conduit for payload data transferred between FX2 and the external peripheral. It can be configured to operate as an 8- or 16-bit interface and can be tri-stated if the system requires it. FD[7:0] represents the least significant byte (LSB) and FD[15:8] represents the most significant byte (MSB).
 

CTL[5:0] (output only)
These are control output signals that can be used to provide signals required by the external peripheral such as read/write strobes, enables, etc.
 

RDY[5:0] (input only)
These are ready input signals that can be used to monitor status outputs from the external peripheral such as FIFO status flags, data available, etc. GPIF has the ability to use these signals as decision point qualifiers for wait-state generation.
 

GSTATE[2:0] (output only)
These are debug output signals that represent the states executed in a GPIF waveform. These are typically connected to a debug port such as a logic analyzer.

The following section presents a design flow methodology for GPIF developers wishing to maximize their "first time success" experience. Although following this methodology may not completely guarantee a 100 per cent success rate, it will definitely give developers the right tools for embarking on a systematic GPIF design approach, which more often than not translates into eventual success. The design examples that are discussed later on in this primer will often refer back to these design principles.

 

Design GPIF Interconnect

Using section 3.2, you should have a pretty good basis for determining how FX2 is going to be connected up to your peripheral device using GPIF. This is also a good time to start collecting the FX2 datasheet and Technical Reference Manual, as well as the peripheral's datasheet as a minimum. You can then start by asking yourself the following questions:

• Is the data path going to be 8- or 16-bit?
  • This decision is often dictated by what size data path the peripheral offers. If it has a 16-bit data path, use it to maximize the bandwidth over the physical interface.
  • Endianness and bit nomenclature may also come into play here so watch how those lines are wired.
  
  
• Will an external IFCLK be used or an internal 30 or 48 MHz clock source?
  • This decision is often made based on how flexible the peripheral is in terms of its own operating modes. For example, if it can accept a 30 or 48 MHz clock input then there's a good chance the internal 30 or 48 MHz clock source can be used to serve as the clock input for the slave device.
     Does the peripheral require any address lines during its read/write cycles?
  • If the peripheral requires any lines to be addressed during a read/write cycle operation, then GPIFADR[8:0] can be used.
  
  
• How many control lines does the peripheral need?
  • Designate GPIF control outputs from your choice of CTL[5:0]. The peripheral may require read/write signals, chip selects, among other control inputs during a read/write cycle. Determine what they are and allocate CTL[5:0] appropriately.
  
  
• How many inputs does the GPIF need to monitor from the peripheral?
  • Determining how many status signals need to be monitored during a read/write cycle usually makes this decision. Determine what they are and allocate RDY[5:0] appropriately.
     

Note: Not all FX2 package types have the complete set of GPIF signals available so the designer has to be mindful of this when determining the GPIF interconnect. The designer also needs to consider what other signals may be used (such as port I/O) to interface the FX2 to the peripheral (e.g. reset signals, other address lines, etc.). For instance, the 56-pin package type does not bring out GPIFADR[8:0]. Therefore, if the peripheral needs some sort of address scheme before a GPIF read/write cycle is initiated, port I/O pins must be used instead (See TI-DSP example for more details).

 

Use Firmware Frameworks 

Before embarking on any firmware project, let alone a GPIF one, it is recommended to start with a firmware frameworks based Keil uVision2 project. Not only will this ensure that the integration and test phase will be smoother, it will also help USB applications support know that you're starting from a well-known and well-tested firmware base. Any of our firmware examples will be frameworks based so you can start with one of those, or start by copying the contents of C:\Cypress\Usb\Target\Fw\FX2 to a new sub-directory. This will allow you to start with a "clean" firmware base. Starting with a firmware frameworks project also allows you to concentrate on the user application code as the USB protocol servicing has been handled already (see the file called fw.c and the development kit documentation for more details).
 

There are basically two major portions to a complete GPIF applications solution:

a) The higher-level firmware that configures the GPIF and launches the transfers (including the rest of the user application code).  

b) The GPIF waveform descriptors that implement the physical bus timing.

Part a) normally consists of five main files (fw.c, periph.c (user can rename this file), dscr.a51, ezusb.lib, usbjmptb.obj) which makes up the Keil uVision 2 firmware frameworks project.

Part b) is typically a self-contained source file that contains the GPIF waveform descriptors and is added to the Keil project. The GPIF Designer a user mode application supplied with the development kit software, exports this "C" language source file.
 

Implement GPIF Waveforms Descriptors using GPIF Designer

As mentioned above, GPIF Designer generates the GPIF waveform descriptors that implement the physical bus timing.    GPIF Designer can implement any of four waveform types: Single Write, Single Read, FIFO Write, and FIFO Read. Each descriptor is 32 bytes long and resides in a special GPIF waveform descriptor area in on-chip memory space, once loaded by the CPU.

It is ultimately the developer's responsibility to create these GPIF waveform descriptors that will, in turn, trigger single or FIFO read/write transactions to the peripheral. The developer has seven states or intervals (S0-S6) to work with before having to terminate the transaction naturally by branching to a "special" IDLE state (S7) (Figure 6 shows an example of a simple waveform broken down into the GPIF state transitions). Once the GPIF waveforms are ready to be exercised by the CPU, the reading or writing of specific GPIF "trigger" registers determine at any one time which of the four waveform types get executed by the GPIF engine.

 
        Figure 6. Illustrating a simple waveform broken down into GPIF states
 

The usage details of the GPIF Designer tool will become clear in the discussion of the two design examples. It is important to note at this point that the first set of waveforms the user should implement is the single read/write transaction waveforms. This will allow the user to flesh-out the physical interconnect and get data moving back and forth between the USB host, FX2, the peripheral, and back. It's always wise to start by implementing single read/write waveforms before leaping into the more conceptually difficult FIFO read/write transactions, because getting comfortable with GPIF and that first confidence booster is essential to a successful design. It may sound like starting with single transactions is a waste of time, but taking the time to absorb the learning curve up front will pay large dividends in the end.
 

Implement Single Read/Write transactions

The main goal of implementing single read/write transactions is to be able to confirm that the physical interconnect is sound between GPIF and the peripheral, and that basic data movement can be achieved in the final system. It is possible to get an entire design working even if only single transactions are utilized. Another advantage of performing this stage first in the GPIF development cycle is that all areas of the system (hardware, firmware, software) can be verified within a relatively short period of time (compared to jumping into FIFO transactions first). Especially for first time users learning about the GPIF, this is a heavily recommended development stage to go through.  

Even though single transactions are the easiest of GPIF waveforms to implement, it may take several iterations of integration and test of the GAS project before the user is happy with the initial design, since this stage can be also considered as the "fleshing out" stage. There may be hardware-timing issues that pop up, hardware connection issues, firmware code flow issues, driver issues, etc., but this is the right time to become aware of these types of issues in order not to get burned too much later on if a problem arises.
 

Implement FIFO Read/Write Transactions

Once the user is satisfied with the single transaction implementation, the next logical step is to implement GPIF FIFO Read/Write transactions to achieve higher bandwidth numbers. This development stage is a two-phase process in itself because it is highly recommended that the FIFO Write waveforms be implemented and tested first. FIFO Write transactions are always the easier to implement out of the two types. The user can perform a FIFO Write transaction and verify the integrity of the data on the peripheral side, and if the data looks good then implementing FIFO Reads is the next step. This is an important accomplishment because it will rule out the FIFO Write code as the culprit if problems arise with the FIFO Read waveform. Otherwise, you will never know which side is truly at fault if each operation is not implemented and tested independently.

At this development stage, there may be also several iterations of integration and test before the user is happy with the overall performance of the design. Issues such as meeting setup and hold time arise, especially for synchronous applications where the main reference for GPIF operations becomes the external IFCLK or the internal 30/48MHz clock source.

Optimize if Necessary

In generating the GPIF waveforms, the user may initially decide to be generous with the physical bus timing. So, there may be room for improvement to cut down the cycle time for each GPIF transaction and still meet the timing parameters required by the peripheral. The design may also be revised to improve firmware code efficiency and overall firmware code flow at this stage.

Summary

This section has discussed a GPIF application development flow that uses a systematic approach to help ensure a successful GPIF design the first time around. Although it has been touched on at somewhat of a macro level, it gives the user a good feel for the amount of effort involved and an approach to tackle a GPIF design from start to finish, no matter the skill level possessed. Figure 7 summarizes this section in an ADFM Flow Diagram. The sections ahead discuss the two design examples that will dive into the hardware, firmware, and software necessary to implement them.